在istio使用後,為了因應服務網格中的各種情況,我們需要一個能知道服務狀態的機制來幫助我們管理服務。這時可以透過sidecar進行各種可觀測性,包括:
Metric: istio 根據四個指標,包括請求的延遲、經過系統的流量、經過系統的錯誤與資源利用的飽和度
Distributed Traces: istio 可以紀錄請求在每個節點上服務的訊息,並提供請求路徑與延遲的可視化
Access Logs: istio 提供一組可設定的格式,用來產生經過服務流量的Access Logs,以此紀錄各種訊息
istio 提供的觀測性功能,我認為是蠻全面的,要全部都嘗試過會是一大工程,所以各位根據各種需求可以去找尋對應的解決方案,今天就先用isito中最簡單的紀錄日誌功能-Access Logs來給各位看效果
當我們在安裝istio時,profile=demo就預設有啟動Access Logs了,除非安裝時使用其他profile 不然不用多作其他配置。
kubectl apply -f samples/sleep/sleep.yaml
apiVersion: v1
kind: Service
metadata:
name: helloworld-service
spec:
type: ClusterIP
selector:
app: helloworld
ports:
- protocol: TCP
name: http
port: 5000
targetPort: 5000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v1
template:
metadata:
labels:
app: helloworld
version: v1
spec:
containers:
- name: helloworld-v1
image: allenku0/hello-api:v1
ports:
- containerPort: 5000
resources:
limits:
cpu: 500m
requests:
cpu: 200m
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v2
template:
metadata:
labels:
app: helloworld
version: v2
spec:
containers:
- name: helloworld-v2
image: allenku0/hello-api:v2
ports:
- containerPort: 5000
resources:
limits:
cpu: 500m
requests:
cpu: 200m
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec "$SOURCE_POD" -c sleep -- curl -sS -v http://helloworld-service:5000/api/details
4. log 結果
kubectl logs -l app=sleep -c istio-proxy
透過以上可以知道sidecar 會幫我們紀錄經過的流量,包括outbound、status code等,可以以此作為服務檢查的依據,當然者只是最基本的功能,可以簡單紀錄服務的流量狀態。
今天就到這邊,我們明天再見!